The present invention relates to control over an OS (operating system) in a computer system.
According to a known technique, when an OS performs communication for sending a processing request to another OS, the processing request is temporarily stored in a delayed request queue. When the receiving OS has received a processing request, the receiving OS retrieves the request from the delayed request queue by interrupt handling and executes processing of the request. According to this method, even if the sending OS locks resources, an interrupt handler of the receiving OS can be executed. Therefore, interrupt handling of the receiving OS is not delayed (see Japanese Laid-Open Publication No. 2001-282558).
According to the known technique, when communication for a processing request is performed between the OSes, the request is processed by interrupt handling. In general, when interrupt handling is performed, it is necessary to store all registers of a CPU (central processing unit), and storing all resisters requires time. Moreover, if the CPU includes an instruction prefetch mechanism, the mechanism does not function and thus execution of an instruction is delayed.
Another technique for operating, as a task running on an host OS, another OS (guest OS) or an application program is possibly used. In this technique, an interrupt handler or a task running on the guest OS is operated under rules defined in the host OS. However, where the host OS performs exclusive control of some resources, in order to avoid a resource conflict, a guest OS interrupt is also prohibited.
When a task running on the host OS issues an API (application program interface), more specifically, an OS service call and, as a result, a need for starting or stopping the task arises, an API processor of the host OS transmits a request for start, stop or the like to a scheduler for processing the request. The scheduler locks resources so as to indicate that the scheduler is in operation when the scheduler itself is operated. In this case, interrupt is prohibited to avoid a resource conflict. Thus, even if interrupt to the guest OS occurs, interrupt handling of the guest OS is performed after the lock is released. Moreover, in the interrupt handler of the guest OS, when a guest OS interrupt is not prohibited, issuing an API, which might cause a resource conflict, has to be prohibited. In the same manner, issuing an API from the application program is restricted. Therefore, in the known computer system, there arises such a problem that operations of the guest OS and application program are influenced by an operation state of the host OS and thus are delayed.